Sensor device having configuration changes

ABSTRACT

Methods and apparatus for configuring a sensor device in accordance with a first configuration defining data collection for a plurality of sensors and defining when the collected data for the sensors is transmitted to a remote network. The sensor device can be coupled to a shipping container for collecting environmental data as the shipping container is en route to a destination. The sensor device can receive a transition signal from the remote network instructing the sensor device to transition to a second configuration with different transmission parameters.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/585,153, now U.S. Pat. No, 11,042,829, filed on Sep. 27,2019, which is a continuation of U.S. patent application Ser No.16/039,904, filed on Jul. 19, 2018, which is a CIP of U.S. patentapplication Ser. No. 15/383,762, filed on Dec. 19, 2016, which claimspriority from U.S. Provisional Patent Application No. 62/269,090 filedon Dec. 17, 2015, entitled “MULTI SENSOR DEVICE WITH CONNECTIVITY ANDSENSING AS A SERVICE PLATFORM AND WEB APPLICATION,” all of which arehereby incorporated by reference.

BACKGROUND

Sensing has promoted technological innovation and has led tominiaturization of many types of sensors. The miniaturization of sensorssuch as accelerometers, gyroscopes, and magnetometer has occurred mainlydue to the advances in Microelectromechanical Systems (MEMS) and hasenabled the industry to combine many similar sensors in small areas. Thechallenge, however, is in intelligently and efficiently combiningconnectivity modules with sensors so that the sensor readings andmeasurements can be stored on the Internet (e.g., in the cloud in datacenters), which then can be consumed and analyzed by various end-partiesfor various applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a perspective view of an exemplary electronic multi sensordevice in accordance with one or more embodiments.

FIG. 1B is an exploded view of the FIG. 1A device.

FIG. 1C is another exploded view of the FIG. 1A device.

FIG. 1D is another perspective view of the FIG. 1A device.

FIG. 1E is a chart showing exemplary power button inputs and LED outputsfor the device in accordance with one or more embodiments.

FIG. 2 illustrates an exemplary application for an electronic devicewith an adjustable strap in accordance with one or more embodiments.

FIGS. 3A and 3B illustrate an exemplary PCB layout for an electronicdevice with WWAN connectivity and multiple sensors in accordance withone or more embodiments.

FIGS. 3C and 3D illustrates an exemplary PCB layout for an electronicdevice with two PCBs in accordance with some embodiments.

FIGS. 3E and 3F illustrates an exemplary PCB layout for an electronicdevice with a surface mount WWAN antenna in accordance with someembodiments.

FIG. 4 illustrates an exemplary asset tracking process in accordancewith one or more embodiments.

FIG. 5 illustrates an exemplary tamper-proof tracking application inaccordance with one or more embodiments.

FIG. 6 illustrates an exemplary mesh-network configuration for multipleelectronic devices in accordance with one or more embodiments.

FIG. 6A is a schematic representation of an example system havingmultiple sensor devices in communication with each other for pooledbattery usage.

FIG. 7 illustrates an exemplary solar panel theft-prevention applicationin accordance with one or more embodiments.

FIG. 8A and 8B illustrate an exemplary ambient light detectionapplication in accordance with one or more embodiments.

FIG. 9 illustrates an exemplary application in which an API isintegrated with other external APIs in accordance with one or moreembodiments.

FIG. 10 illustrates an exemplary asset track, sense, and traceapplication in accordance with one or more embodiments.

FIG. 11 illustrates an exemplary security implementation from anelectronic device to the cloud in accordance with one or moreembodiments.

FIG. 12 is a block diagram illustrating an exemplary cloud basedarchitecture for accepting and sending data to electronic devices inaccordance with one or more embodiments.

FIG. 13 is a block diagram illustrating an exemplary cloud basedarchitecture in accordance with one or more embodiments for processingdata that is obtained by an electronic device and data from external APIcalls.

FIG. 14 illustrates an exemplary usage of dual SIM cards in order toachieve cost effective global coverage using minimum number ofelectronic device product Stock Keeping Units (SKUs) In accordance withone or more embodiments.

FIGS. 15A and 15B illustrate an exemplary spectrum monitoringapplication from an electronic device to a cloud based Sensing as aService Platform and Web Application in accordance with one or moreembodiments.

FIG. 16 illustrates an exemplary loss of connectivity scenario andmanagement of data in areas where there is no available connectivity tocloud for a system in accordance with one or more embodiments.

FIG. 17 illustrates an exemplary connection of an electronic device tothe cloud through a combination of WPAN, WLAN, and/or WWAN enabledwireless communication in accordance with one or more embodiments.

FIG. 18 is a flow chart illustrating an exemplary process for minimizingpower consumption in an electronic device in accordance with one or moreembodiments.

FIG. 18A is a flow diagram showing an example sequence of steps forchanging a configuration of a sensor device.

FIG. 18B is a representation of a route deviation for a sensor device.

FIG. 18C is a representation showing configuration changes correspondingto waypoints for a sensor device.

FIG. 19 is a chart illustrating new features available for new LTEstandards in order to support low power connectivity.

FIG. 20 is a flow diagram illustrating an exemplary mechanism ofcollecting and sorting data for sensors in accordance with one or moreembodiments.

FIG. 21 is a flowchart illustrating an exemplary process to improve dataverification and integrity from a device in accordance with one or moreembodiments.

FIG. 22 illustrates an exemplary process combining GPS/GNSS, cellularlocation, and Wireless Personal Area Network to get an accurate locationof a device depending on connectivity in accordance with one or moreembodiments.

FIG. 23 illustrates an exemplary network diagnostic application inaccordance with one or more embodiments.

FIG. 24 is an exploded view of an exemplary electronic device inaccordance with one or more embodiments showing various antennaplacements for GPS/GNSS, WWAN, WPAN, and WLAN connectivity.

FIG. 25 illustrates an exemplary application for monitoring pallets andreusable plastic containers using an electronic device in accordancewith one or more embodiments.

FIG. 26 is a screenshot illustrating an exemplary primary dashboardinterface of Sensing as Service Platform in accordance with one or moreembodiments.

FIG. 27 is a screenshot illustrating an exemplary web applicationsettings interface in accordance with one or more embodiments.

FIG. 28 is a perspective view illustrating alternate exemplary casedesigns of an electronic device in accordance with one or moreembodiments.

FIG. 29 illustrates an alternative exemplary case design of anelectronic device in accordance with one or more embodiments.

FIGS. 30A and 30B illustrate an exemplary PCB layout for an electronicdevice in accordance with one or more embodiments where the USB type Cconnector is also utilized as a MCU programmer/debugger.

FIG. 31 is a flow chart illustrating an exemplary sensing as a serviceprocess in accordance with one or more embodiments.

FIG. 32 is a screenshot illustrating an exemplary alert perimeter for alocation sensor in accordance with one or more embodiments.

FIG. 33 is a block diagram illustrating components of an exemplaryelectronic device in accordance with one or more embodiments.

FIG. 34 is a flow chart illustrating an exemplary user sign in and signup process in accordance with one or more embodiments.

FIGS. 35A and 35B are top and front views, respectively, of analternative exemplary case design for a device in accordance with one ormore embodiments.

FIGS. 35C and 35D are side and top views, respectively, of a clip thatcan be removably attached to the case of FIGS. 35A and 35B to secure thedevice to an asset in accordance with one or more embodiments.

DETAILED DESCRIPTION

Various embodiments disclosed herein relate to electronic devices withmultiple sensors that can report the various sensor readings andmeasurements relating to an asset using wireless connectivity to aremote computer system operating a sensing as a service platform and aweb application. The devices can be used to monitor, track, or trace avariety of assets including, but not limited to, packages, pallets,containers, animals, and people.

The sensor devices can communicate using various wireless communicationprotocols, and reference throughout the specification to wirelesscommunication can include communication protocols and methods other thanthose used to illustrate the exemplary embodiments described herein.

The term sensor as used herein broadly refers to generally any type ofsensor that is capable of monitoring ambient or device statecharacteristics. Such sensors include, but are not limited to, sensorsfor temperature, humidity, pressure, volatile organic compound (VOC)detection, ambient light sensing, infrared sensing, accelerometer,magnetometer, gyroscope, GPS/GNSS receiver, radio frequency (RF)spectrum power sensing.

Reference herein to a remote computer system or to the cloud can includea variety of database architectures, data centers, remote servers ormachines, remote APIs, and the internet in general.

Measuring and sensing various environmental conditions and states hasmoved the market and technological innovation toward miniaturization ofmany sensors and connectivity modules. The movement has been mainly ledby mobile computing devices such as smartphones, tablets, and otherswhich typically include electronic sensors such as: ambient lightsensors, GPS/GNSS receivers, accelerometers, gyroscopes, and magneticfield sensors (magnetometers). However, smartphones that are availabletoday do not contain environmental sensing and monitoring capabilities.The advantage that smartphones have is their capability to connect tothe Wireless Wide Area Network (cellular network or others), theWireless Local Area Network (WLAN), such as WiFi, and Wireless PersonalArea Network (WPAN), such as Bluetooth, Bluetooth Low Energy (BLE), orBluetooth Smart. Smartphones are designed to stream a great deal of datafrom and to the internet, with battery lifetimes ranging from 6 to 12hours. Such a limited battery lifetime is not sufficient for sensingapplications in which minimal or no recharging is required by the enduser. This smartphone advantage, however, comes at cost, such as thehigh price of smartphones with power hungry processors, not being ableto effectively sense environmental conditions such as humiditytemperature pressure, and others, and requirements by their users tosign complicated contracts and pay large costs for various data plans tocellular network operators.

FIG. 1A illustrates an exemplary multi sensor electronic device 100 inaccordance with one or more embodiments. The device 100 has an outercase with a power button 108, which is used to turn on and off thedevice 100. The power button 108 can also be used to check the batterylife of the device by pressing the button for a short time (e.g., lessthan a second). In one or more embodiments, a single multi-color (red,green, and blue) LED light 102 is used to indicate the status and thestates of the device. The functionalities that the notification LED 102can show include: battery power, cellular connectivity, GPS/GNSSconnectivity, WPAN/WWAN connectivity, various malfunctions, an OK (allgood) status, and other features of the device. The blinking of the LED102 and its colors can be programmed to indicate these features andvarious other notifications. The power button 108 pushing sequence andpushing length can also be programmed such that these various states ofthe device can be checked, or device actions can be performed.

The type C USB port (or other port such as, e.g., a mini or micro port)110 is a multi-function port that can be used for one or more of thefollowing: (1) for charging the battery, (2) to connect an externalbattery and extend the operation of the device, (3) to power the devicewhere the LED 106 would light up, (4) to configure the device and updatethe firmware, and (5) to send other data such as sensor data through USB110. This USB can also be utilized to communicate using other protocolswith an adapter for UART/SPI/I2C or others and then sending data usingthose other protocols. In addition, the USB port can be used to connecttwo or more devices together so that they can share data between theirsensors, processors, and/or their modules and utilize each other'swireless communication capabilities. There are multiple sensors placedon the device and some embodiments involve sensing of environmentalconditions, ambient light, and/or infrared light. In order to performthese functions, the device utilizes sensors that measure: temperature,humidity, pressure, and light, which sensors are not encapsulated insidethe device's case. In one embodiment, an opening window 104 is providedenabling air flow and light to enter the device case. Thegeneral-purpose hole or lanyard hole 112 can be used for attaching thedevice to keys, bags, cars, and other things.

FIG. 1B illustrates an exploded view of the electronic device 100 wherevarious internal parts are shown in more detail. The case cover 120contains a logo and also the lanyard hole 112. The device includes aGPS/GNSS antenna 122, which can be a flexible omnidirectional antenna.The battery 124 is placed on the device and it could be smaller orlarger than the one shown in the figure. The device includes a Bluetoothor WiFi antenna, which is preferably a chip antenna 126 to take leastamount of space. The type C USB connector 130 for recharging the batteryis also used to program the micro controller. The main PCB 132 and theside PCB 134 of the device are connected using a ribbon type cable 128.The side PCB 134 also contains a light sensor 136 and thetemperature/humidity/pressure/volatile organic compound (VOC) sensor138. The device includes an alarm buzzer placed in the circle shapedspace 140 for a good fit of the buzzer. A double-sided tape or otheradhesive can be used to attach the buzzer to the case such that it cancause vibrations and sound can be emitted out of the device.

FIG. 1C illustrates another angle of the device showing a 2G/3G/4Gantenna as a PCB antenna 152, the buzzer 154, and a cellular module 150.The antennas can be designed for world-wide coverage.

FIG. 1D shows the device from a perspective in which LED 160 and powerbutton 162 are both visible. Power button 162 is used to switch thedevice on or off, check status, and push data to the cloud. Each ofthese actions is accomplished by different inputs using the power buttonand results in an output from the LED 160, in the form of either red,green or blue light combination. Each of these actions, with theirrequired inputs and LED outputs are outlined in FIG. 1E.

The electronic devices described in accordance with the variousembodiments disclosed herein can be the same as or similar to the device100 of FIG. 1A.

FIG. 2 shows an electronic device 200 in accordance with one or moreembodiments enclosed in a case 202. The case is preferably manufacturedusing high durability silicone, and is malleable to insert the deviceinto the front opening. When enclosed, the entire device and case haveincreased water resistance. Built-in case loops 204 provide securementpoints for adjustable collars of multiple sizes depending on theapplication.

FIGS. 3A and 3B show the opposite top and bottom sides of an exemplaryPCB layout for an electronic device in accordance with one or moreembodiments with WWAN connectivity and multiple sensors on board inaccordance with one or more embodiments. In one embodiment a small sizePCB 302 at 40.times.40 mm is used containing WWAN connectivity module, atemperature sensor, a humidity sensor, a pressure sensor, an inertialmeasurement unit sensor, an alarm buzzer, and an on board PCB antenna304 to meet 2G/3G requirements.

FIGS. 3C and 3D show an exemplary PCB layout (top and bottom views ofthe PCB) for an electronic device in accordance with one or moreembodiments where two PCBs are shown in accordance with someembodiments. The PCB sides 312, 314 show the top side of the 4-layerPCB, whereas the PCB sides 310, 316 show the bottom side of the 4-layerboard. This shows the version of the overall PCB that is purposefullybuilt for manufacturing, the PCB 316 can snap off from PCB 310. In oneembodiment the PCB 316 is the WPAN connectivity module, in thismulti-color LED indicator.

FIGS. 3E and 3F show an embodiment of a PCB layout (top and bottom viewsof the PCB) for an electronic device with a surface mount WWAN antennain accordance with some embodiments. This device contains the sameconfiguration as shown in FIGS. 3C and 3D. Reference numbers 322 and 324indicate the opposite top and bottom sides of the PCB that uses asurface mount antenna (not a PCB trace antenna as in FIGS. 3A and 3B).

FIG. 4 shows an exemplary asset tracking application using the device402 in accordance with one or more embodiments. The device is used totrack and trace packages 406 during transportation in this example. Inone embodiment, the multi-sensor electronic device with wirelessconnectivity can be utilized to track/monitor the location, temperature,humidity, pressure, presence of VOCs, motion, handling, and see if thepackage has been opened by interpreting data from an ambient lightsensor or a proximity sensor. The update rates for each measurement canbe modified remotely and can be programmed to connect to the cloud every30 seconds, 1 minute, 5 minutes, 10 minutes, 30 minutes, 60 minutes, 6hours, continuously, or any other time interval that is desired formonitoring of the package during shipment.

The tracking of the package can be visualized from its source to itsdestination. The pressure sensor and the accelerometer on the device canbe used to determine the shipping method: ground or air. If the packageis being transported by ground the pressure sensor will sense a certainrange of pressure values that correspond with measurements of less thana few thousand feet above sea level and accelerometer readings that cancorrelate to accelerometer reading produced by an automobile. If thepackage is being transported by air, the pressure sensor will detectpressures that are greater than 10,000 feet above sea level, and senseaccelerations within in a time period that can only be produced by anaircraft during takeoff 408 or landing 410. This mechanism can also beused to remotely turn off all radios on the device to comply with FAA orother flight regulations. Turning off the radio causes the device tostop sending sensor measurement data to the cloud. However, the devicecontinuously monitors the status of the package and stores the readingsin its memory. The advantage of the device is that it has an externalmemory that communicates to the micro-controller and it can store allsensor data with timestamps during transportation of the package. Onceconnectivity conditions are met, the WWAN, WLAN, or WPAN radios areturned on to establish connectivity to the cloud and transfer the databased on the available wireless connections to the cloud.

Devices In accordance with various embodiments can be operated invarious other configurations. For instance, in one example, the devicecan be configured to stay in sleep mode until there is a movement of thepackage detected by analyzing the accelerometer sensor data. Once themovement is detected the package can be tracked and traced continuouslyfor a certain amount of time, or indefinitely until it runs out ofbattery power depending on the setup by the end user. This feature couldallow the device to operate longer and save on its battery power. Inanother example, the device can be configured to be in sleep mode andonly wake up once there is a change detected by the ambient lightsensor. Such as package being opened 412, or any other scenario wherethe ambient light sensor can change due to light 414 exposures. In afurther example, the device is configured to continuously tracktemperature or humidity and it can bet setup to send an alert once aparticular threshold is reached, enabling the safe and efficienttransportation of items that are sensitive to temperature or humidity.In another example, the device is configured to monitor how the packagehas been handled by using the accelerometer sensor. For example, if afragile package is thrown, tossed or moved in an undesired fashionduring shipment, this data can be stored and reported back to the cloud.This can also apply for the orientation of the shipment as there areshipments that require particular orientation during transportation,such as refrigerators, stoves, and other appliances. The device can beattached inside the box used to transport these items and theorientation can be tracked and recorded in real-time.

FIG. 5 illustrates an exemplary motion detection application inaccordance with one or more embodiments. In this example, there arevarious items stored in a warehouse (location) 510 where they aresupposed to be stored for multiple days or weeks and not be tamperedwith. For these types of applications, the device 500 can be placedinside a pallet 504, boxes 506, parcels 502, or other assets in awarehouse (other facilities). The device then can be programmed to stayin sleep mode until there is an actual motion detected by theaccelerometer or gyroscope motion detector chipset. This motion can leadto the device waking up and sending a signal to the cloud and informingthe end user that there has been tampering on the asset or item at whichthe device was placed in.

In another illustrative embodiment, the device 500 is placed in one ofthe assets shown below it: a package 502, a pallet 504, or any otherasset 506. The assets are inside a warehouse, but they could be anywherewhere tampering of the assets is not permitted for a certain period oftime. In this case the device 500 is configured such that the majorityof time is kept in sleep mode and once motion is detected it wakes upand utilizes the WPAN, WLAN, or WWAN connectivity 508 to sendinformation to the cloud about the whereabouts of the device, usingGPS/GNSS based location, cellular based location and also sendadditional information regarding the motion detection due to tamperingof the tracked device and the abrupt changes on the accelerometer orgyroscope readings.

FIG. 6 shows an exemplary mesh network application in accordance withone or more embodiments with a combination of personal and Wireless WideArea Network modules and chipsets. In one or more embodiments, a meshnetwork between the devices 602, 604, 606, 608, 610, and 612 is createdusing either USB connection or Wireless Personal Area Network (WPAN)connectivity such as Bluetooth, Bluetooth Low Energy, Bluetooth Smart,ZigBee, Z-Wave, or other low power wireless communication protocols. Inthis scenario, even though all of the devices (two or more) have WWAN614 connectivity such as cellular, LoRa, Sigfox, or others, one of thedevices is assigned to be the master (or designated device) to connectthrough WWAN 614 such as shown in FIG. 6 where only device 612 isconnected to the WWAN.

In another embodiment the device containing WWAN+WPAN+WLAN, WWAN+WPAN,or WWAN+WLAN connectivity combinations could be utilized for best powerconsumption. In one or more embodiments, six devices 602, 604, 606, 608,610, 612 are shown. Initially, device 612 is connected to WWAN, and thedevice 612 will remain connected to the WWAN network for as long as thebattery of the device reaches a certain percentage, such as 20%, 30% orany other percentage threshold. All the sensor readings from the otherdevices will be transferred to the WWAN connected device 612 throughWPAN or WLAN through mesh or direct transfer method. Once that batterythreshold is reached, the WWAN connectivity is turned off at the device612 and WWAN of the next device 610 is utilized, and this continues withall other consecutive devices until the batteries of all devices arefully consumed as WWAN connectivity is a power hungry module whencompared with the other modules inside the electronic device. The dataflow in this example goes from device 612 to 610 through WPAN or WLANconnection, and 610 then sends the received data to the cloud throughits WWAN connectivity.

FIG. 6A shows a first sensor device 650 (e.g., device #1) and a secondsensor device 652 (e.g., device #2). In embodiments, the first andseconds sensor devices 650, 652 have sensors and connectivity asdescribed above. In the illustrated embodiment, the first device 650 isconnected 654 to the cloud 656, such as by a cellular link, and to thesecond device 652, such as by a BLUETOOTH link 658. The second device652 may be connected to the cloud 656 via a link 660.

The first sensor device 650 includes a battery 662 having a batterylevel 664. Similarly, the second sensor device 652 also includes abattery 666 having a battery level 668. The first and second sensordevices 650, 652 can pool their battery power to conserve power andefficiently transmit information to the cloud and to each other.

For example, the first and second devices 650, 652 have high-powerconnectivity, e.g., cellular links 654, 660, and low-power connectivity,e.g., BLUETOOTH links 658, that enable device interaction in order toincrease the battery life of the overall system. Assume that the firstdevice 650 is fully charged 100%, and then goes off to a journey, andreports sensor and/or signal spectrum data, using cellular (WWAN highpower) connectivity 654 to the cloud 656 every five mins for the next 10days so that battery power decreases to 0%. In this scenario, batterypower is not extended.

In an example embodiment, the second device 652 communicates with thefirst device 650 via a WPAN or WLAN link 658 and sends data in a lowpower mode to the first device 650 every five minutes. After 8 days, forexample the battery power on the first device 650 drops to say ˜20%, andbattery power on the second device is at say 90+% due to low powerconnectivity usage. At this threshold, when the first device 650 reaches20% (or other pre-determined value), the roles reverse and first device650 starts transmitting to the second device 652 every 5 mins using lowpower (BLE, WiFi, or others) connectivity 658 and the second device 652transmits using high power links 654 until the battery power is drainedto say 20% on device 652. In embodiments, the first and second devicescan ping-pong connectivity modes until respective battery powers each10%, 5%, and 0%, for example. With this arrangement, data for bothdevices is aggregated to one device for high power transmission so as topool and extend battery life for the devices.

The first and second devices 650, 652 only using high power connectivityleads to a 10 day, for example, battery life. Using high and low powerconnections of the first second devices 650, 652 pools and extendsbattery life to 8+8=16 days, for example, of 5 minute interval reportingduring a journey with the two devices. As the number N of devicesincreases, the number of days of aggregate battery power also multiplesby at least X*N. It will be appreciated that the less power used for lowpower connectivity, the closer to 1 variable X gets. In embodiments, thebattery power for multiple devices is pooled to extend the battery lifeof the multiples devices by effective low power and high powercommunication.

FIG. 7 shows an exemplary application for tracking and tamper-proofingsolar panels 704 in accordance with one or more embodiments. The device702 in this case is attached to the solar panel 704 to ensure that thesolar panel is not tampered with and moved from the installed location.This is used for theft prevention of the solar panel or other assetsthat are outdoors. In this case, an ambient light sensor can also beutilized to track the sun light shining directly on the solar panel. Inone embodiment, the device 702 is attached or is part of the solar panel704. The device 702 is configured to send periodical location andorientation data. In one or more embodiments, the update rate is set toonce or twice a day, which is fairly infrequent. The device is alsoconfigured to detect abrupt motions or tampering with the solar pane.Once the tampering occurs, the device wakes up and the update rate ischanged to a more frequent rate such as every 30 seconds or every minuteto be able to accurately track the whereabouts of the solar panel 704.

FIGS. 8A and FIG. 8B show the device 802 with the ambient light sensorand temperature sensor. In one or more embodiments, the ambient lightsensors will change intensity based on the sun 806 and or the otherindoor or outdoor light source 808. The graphs in FIG. 8B show thecorrelation that can be done between the lux values 816 and temperaturereadings 814 to make sure that the temperatures are being read outdoorsinstead of indoors. The temperature correlation can help furthervalidate the data and that can be shared with other third party vendorsthrough APIs. In addition, to further validate the indoor or outdoorlocation of the device, the APIs from weather prognosis can be utilizedto determine whether the client's temperature readings from the deviceare outdoor or indoor. Also the GPS/GNSS reception signals can be usedto determine the device's precise location indoor or outdoor due to GPSmostly being available outdoors.

FIG. 9 illustrates an exemplary application in accordance with one ormore embodiments where the data from the device 902 is anonymized,packaged and sold to or used by other third party applications such asNest, Honeywell, Weather Channel, AccuWeather, IFTTT app, and manyothers 912. The API calls 910 can be tailored specifically for eachapplication and the user data can be anonymized or remain non-anonymizeddepending on the application.

FIG. 10 shows an asset tracking application using the device 1002 inaccordance with one or more embodiments. The device, which is batterypowered, small, and compact, is an ideal device for tracking theenvironmental states and location of assets. For instance, the device1002 can be placed in a bicycle 1006, car 1008, truck 1010, luggage1012, package 1014, pallet 1016, or any other asset 1018. The sensorreadings are then sent out to the cloud through its wirelessconnectivity 1004 capabilities. The device could be attached to anyassets and be tracked and monitored throughout a period of time. Thedevice can be configured to monitor particular metrics that are ofinterest for that asset, such as temperature, humidity, pressure, andany other sensible metrics that are part of the device. The asset 1018could be monitored at various time intervals and then wirelessly 1004sent to the cloud. This data could then be plotted or analyzed overtime. The device can be attached to an asset using an adhesive, byutilizing the general-purpose hole, or by implementing the use of acustom case and potentially waterproofing the device.

In accordance with one or more embodiments, the remote computer systemcan change the reporting time period of the device in order to optimizethe device's power savings depending on external factors that aredetermined by the remote system. One example of such an external factoris the device (and associated asset) being determined to be stuck incustoms, or stuck over the weekend when carriers/shippers are notworking. The remote system can algorithmically determine that this isthe best time to change the device's reporting time period to stretchthe battery life of the device. The selected changed reporting timeperiod can vary depending on analysis by the remote system.

FIG. 11 shows an exemplary security implementation in accordance withone or more embodiments from a device 1102 to cloud while ensuringminimum data transmission. In one or more embodiments, various possiblecommunication protocols shown in 1106 include TTP, HTTPS, MQTT, MQTTS,CoAP, XMPP, RESTful HTTP, and any other internet of things relatedprotocols that could be utilized. When communicating and sending dataover cellular network, there data usage costs associated with the use tonetwork infrastructure, whereas costs are negligible with WiFi orBluetooth, compared to cellular. The device reduces the amount of datasent while maintaining a high level of security. One of the ways toprovide security is through the SSL protocol, which demands largerpayloads due to overhead. The payload becomes bigger through SSL, andthe computational power required for the encryption algorithms for SSLis quite high for a device that has a relatively limited power supplyand requires a long battery lifetime. It should be noted that theincrease in communication payload, as it relates to cellularcommunication, raises costs for the end user due to data usage. Inaddition to cost, computation requirements on SSL are demanding, whichthen increase power consumption of device and reduce overall batterylifetime. In order to keep the device secure and at the same time reduceoverhead requirements of SSL, one embodiment is shown where theencryption occurs on the device using AES128, AES256 or other encryptionalgorithms. The encryption keys are stored in a secure server for eachdevice, and when the device 1102 is programmed the key is securelystored on the device. Only the secure server 1108 and the device 1102have the key for that particular device and the data sent is encryptedwith the private key from the device and then also decrypted with thatunique key on the cloud 1108. The device identification is then comparedwith the decrypted data to make sure that the data is coming from theactual device. The data is never the same as there is a random keygenerator that sends a one, two, or more letter/number combination,which is different for every transaction and that is also part of theencrypted message 1110.

FIG. 12 illustrates an exemplary device and cloud architecture and howthe data flows from the device to the actual database tables on thecloud. In one embodiment, the cloud platform could be custom, or itcould utilize one of the well-known cloud platforms such as Google CloudPlatform, Amazon AWS, Microsoft Azure, or other custom platform. Inanother embodiment the device 1202 sends the sensor data, spectrum data,network characteristics data, and any other data available from thedevice such as Bluetooth network characteristics and any Bluetoothbeacons that the device can sense around its area. There are multiplePOST/GET methods that can be utilized to send the data to the server asalso described in FIG. 11 where different protocols could be implementedand used. In yet another embodiment, the data is sent using the POSTmethod 1218 as an HTTP request to the server. Once the Device API 1216receives the data it runs through multiple checks to validate that thedata is coming from a real device, it has not been altered, and that theserver is not being attacked with malicious hits. In order to read thedata, the decryption 1214 of the data is performed. The decryptionhappens using a key that is unique to the device. The keys are securelystored internally on the device and on the server and accessed only whendecryption of the data happens. After decryption, the integrity of thereceived and decrypted data string starts with a checksum 1204 such asCRC16, CRC32, or others, if that passes, the length of the data 1206 isverified. For each transaction, there is a unique request ID that isgenerated and this checks if the request ID 1208 is different from thelast transaction. In order mitigate Denial of Service (DoS) attacks, aduplication check 1210 is performed to make sure that the same string isnot being sent over and over again by an unauthorized client, where SSLis not utilized. In this case any duplicate data is ignored, this checkmost likely will not occur as it would have failed the unique request IDcheck 1208. If all of the above checks pass, a last check 1212 ofconfidence is performed to verify that the incoming data from the devicecorrelates with the configuration of the device. For instance, if thedata is being sent every minute and the device is configured to sendevery 15 minutes, this raises a flag. The device is then checked to makesure that the update rate is set to the client's desired update rate ofevery 15 minutes. Device API also communicates back to the actual devicehardware with response such as SUCCESS of reception of data, and/orERROR ###, where ### is an error number corresponding to an issue thatthe device has experienced. Upon successful checks, the device API alsoresponds 1220 to the device for “Successful Reception” of data or anerror code showing the reason why the data reception failed. If thereare any configuration changes on the device, those are also sent at thistime. In addition to responding to the device, the device API sends allthe verified data to a queue for further processing, computation andstorage.

FIG. 13 illustrates an exemplary method in accordance with one or moreembodiments of processing the data that has been placed in queue by theDevice API shown in FIG. 12. After the data has been Queued, theFirst-In-First-Out (FIFO) approach is implemented and scalability willbe executed depending on the latency of the last queued message. As thelatency increases, more resources are allocated to process 1302 thequeued data in parallel. Once the device message is retrieved 1304 fromthe queue, another function also retrieves the last stored message forthat particular device from cache 1308. In order to minimize cellulardata usage, duplicate data from device are ignored and only data thatchanged from the previous message are sent to cloud. This reduces datacharges and creates a de-duplication algorithm from which the deviceoperates in. In order to support this approach to data de-duplication,the API receiving the data requires an additional function 1310, whichcompares the received message with the last cached message. The new datafrom the comparison then is saved in place of the last cached message.After this step, the data is extracted 1320 into multiple fields using aJSON parser or a delimiter parser depending on the data format usedduring transmission, and each field will be stored in its appropriatedata table 1340 1338 1328 1326 1324 1322 1344. Prior to storing the dataon tables, all external APIs are called to extracted further data, suchas street address and mapping points 1312 from longitude and latitudedata received from the device's GPS/GNSS. Another external API that isthe cellular based location API (such as Combain, UnwiredLabs,OpenCellID, and/or others) 1314 is called to obtain an approximatelocation based on the Local Area Code (LAC), Mobile Network Code (MNC),Mobile Country Code (MCC), and CellID information obtained frombase-stations near the device, providing additional information on thelocation of the device if there is no GPS availability. In addition todata related APIs, other APIs 1316 could also be called to furtherenrich the raw data received from the device. Another example ofadditional APIs would be temperature, humidity, and pressure relatedAPI. Based on raw location data, outside temperature, pressure, andhumidity can be obtained using an external API (such as Accuweather,Weather.Com, and/or others) and that data can be stored for future orimmediate correlative comparison to determine whether the device isoutdoors or indoors. In addition, device connectivity management APIs1342 are also utilized to observe connectivity session times, datausage, network carrier information, and others. These data points arethen combined and stored into multiple tables. Raw data from the deviceis stored in a raw data table 1340. Spectrum monitoring data is storedin a separate table 1338, and all the environmental data are stored intable 1326. An additional aggregation function is also performed on theenvironmental data in order to improve the performance and reducelatency at the end user application as shown in FIG. 20. This aggregateddata is then stored in multiple tables 1336 for various time steps. Thesame also occurs for the Inertial Measurement Unit (IMU) data 1328 1334,location and speed data 1324 1332, network characteristics data 13221330, connectivity related data 1344 1346, motion detection data andother data that goes into processing queue.

FIG. 14 illustrates exemplary usage of two or more subscriber identitymodules (SIMs) in order to achieve cost effective global coverage usingminimum number of product SKUs in accordance with one or moreembodiments. In this example, a multiplexer 1404 is connected to two ormore SIM cards inside the device 1402. Each SIM card (1406, 1408, or1410) can be of a different form factor: 2FF, 3FF, 4FF, or embedded SIMcard. In one embodiment, one SIM card 1406 is a micro SIM card (3FF) andthe other one is an embedded SIM card 1408. The embedded SIM card 1408can be used during manufacturing and is assigned to a particular NetworkCarrier or a Mobile Virtual Network Operator (MVNO) or a carrier thatgets optimal coverage at great cost in a few key countries around theglobe. However, there are countries in the world where the optimalcoverage is not available and roaming charges are very high. Forinstance, in Kosovo (a country in Europe) the US+EU28 cell plan whichcovers USA and the 28 countries in EU goes into roaming charges. Theroaming rates are high and are not economical to work with the alreadyassembled embedded SIM card 1408. In this case, a second micro (3FF) SIMcard can be utilized for a specific network carrier in countries wherethe embedded SIM would go into roaming. The microcontroller or processorof the device can be configured to determine which SIM card to utilizebased on GPS/GNSS location, cellular signal availability, and/or lowestdata rate costs at that location.

FIGS. 15A and 15B illustrate an exemplary spectrum monitoringapplication in accordance with one or more embodiments. The device 1502can be configured to measure the RF power across the 2G/3G or 4G bands.For instance, the device is configured to receive power measurement ateach band and channel 1514 of 2G (GSM or others) and 3G (UMTS or others)standards. Once the scanning is complete, each value then is stored inthe microcontroller or processor of the device and the cellularconnectivity module is restarted to transmit and connect to the cloud1510. The stored data is then sent to the cloud with power measurementreadings at each band of the GSM and UMTS standards acting as a spectrumanalyzer 1512 for those bands 1514. The same can also be applied to allthe LTE bands and power at each channel can be reported through aspectrum dashboard 1520. The spectrum analyzer dashboard will showfrequency on the x-axis 1524 and the detected power at that band on they-axis 1526 in terms of dBm or other power metrics. The circled region1522 shows where there are signals in channels in that band.

FIG. 16 illustrates a loss of connectivity scenario and management ofdata in accordance with one or more embodiments in areas where there isno wide area access network connectivity. In one embodiment, the devicecould be placed inside a vehicle 1604 that is being tracked. The vehiclecould be driving by mountainous areas 1608 or areas where there is nocellular coverage, and in this case the device inside the vehicle 1606stores the sensor readings that it collects together with GPS/GNSSlocation into the internal memory 1606. The memory should preferablystore at least 3 days' worth of readings such that if the vehicle isparked where there is no cellular or Wireless Local Area Networkcoverage for more than 3 days, the sensor measurements are still storedand kept in memory. Once the vehicle goes back to an area where there iscellular or other network coverage 1602 to access the cloud, all thedata that was stored in the memory is sent out.

FIG. 17 shows the device connecting to cloud through another WPAN andWLAN/WWAN enabled device in accordance with one or more embodiments. Inthe illustrated example, the device is connected through WPAN 1706(Bluetooth Smart in this case, and others are possible) to a smartphone1704. The device transfers all the sensor readings and other data thatit needs to send 1714 to the cloud 1710 to an app inside the smartphone1704 that connects to the device 1708 directly through WPAN. This canoccur when the device 1708 is synchronized with a smartphone 1704through an app that recognizes the device 1708 and it accepts data fromthe device and then sends it to the cloud 1710 so that it can beconsumed and utilized by a web application, smartphone app, desktopbased software, or other tool. In this case the device could lose theWWAN/WLAN based connectivity, as shown in 1712, and connect to thesmartphone 1704 through its WPAN enabled connectivity to conserve energyand use a lower power solution such as Bluetooth 1706 connection insteadof the device's cellular connection 1712 to indirectly connect to WWANor a cell tower 1702 as shown in one embodiment.

FIG. 18 illustrates a power management flow in minimizing powerconsumption and connecting to the cloud only when it is necessarydepending on thresholds of various sensors. In one embodiment, in orderto meet power consumption requirements such that the device could lastfor a few weeks, months, or years on battery, the most effective way ofachieving this is by setting the device in deep sleep mode 1806 for aslong as possible. Once the device is in sleep mode it should remainthere and consume battery in less than a few nanowatts or microwattssuch that the battery would last the longest time possible. In order toaccomplish this, all the sensors on board are programmed to operate attheir lowest power consumption and only change when there is an eventthat causes the device to wake up. The user has the ability to settransmission period times and manage sensor activity within the WebApplication, Smartphone App, Desktop App, or any other application andstored in the cloud, where then the device would be configuredaccordingly as per user's preferences. In one embodiment we show variousthresholds 1802 that could be set by the end user which could be donethrough an app on a smartphone, desktop, web browser, or other platform.For instance, a threshold alert of 80 degrees F. could be set fortemperature sensor. If a high or low threshold is reached or crossed,sleep mode is interrupted 1804 and the device is fully turned on,wireless connectivity session 1808 is established and sensor readingsare sent. In one embodiment, examples of other thresholds are motiondetection, light sensitivity, location perimeter (as also shown in FIG.32), accelerometer, gyroscope, pressure, humidity. Timing interrupt 1802can also be set such that the device wakes up from sleep mode based on apreset schedule or timer.

In embodiments, the sensor device may be controlled and/or containintelligence to increase battery power usage efficiency. In staticenvironments, it may be desirable to obtain sensor data and/or transmitsensor data less often. For example, if a shipment will remain in arelatively stable environment, such as a warehouse, for some periodtime, it may be a waste of battery power to transmit data that willremain largely unchanged. It is desirable to determine when a shipmentwill be in a stable environment at unknown or unexpected times when enroute, such as cancelled flights, bad weather delays, worker strikes,and the like.

FIG. 18A shows an example device reconfiguration to increase batteryusage efficiency. In step 1850, the sensors on the device are configuredto take measurements at selected time intervals and/or certain events.In step 1852, the device is configured to transmit at least some data atgive time intervals, e.g., five times per hour, and/or in response tocertain events. In step 1854, the sensor device stores sensor data andin step 1856 the device transmits the stored data at the configured timeintervals. In step 1858, it is determined whether a configuration changehas been sent via the cloud and received by the device. In embodiments,a sensor device can determine whether a configuration change should beimplemented based on an event, for example. If there is no change,processing continues in step 1854. If there is a change, in step 1860,the device is reconfigured to implement the change(s) and processingcontinues.

As an example, a sensor device that is tracking a shipment is stuck incustoms on Friday afternoon. The probability of the shipment clearingcustoms on Friday is low. Without this knowledge, if the device isconfigured to transmit every 5 minutes, the device continuestransmitting throughout the weekend which may waste significant amountsof battery power. In embodiments, the cloud and/or device recognizesthat shipment location is customs on a Friday afternoon and determinesthat the device will remain in customs until Monday. The cloud and/orsensor device then changes sensor data transmissions from every fiveminutes to every 6 hours until Monday morning at 8am (local time) inorder to save a significant amount of battery life.

In another aspect, a sensor device can reconfigure one or more settingsin response to a deviation from a planned route. For example, a sensordevice is coupled with a shipment with a predetermined route that ismapped to be within 2 miles of interstate 1-90 at all times. If thesensor device transmits location data to the cloud, it can be determinedthat there has been a route deviation. In response to the routedeviation, the cloud can command the sensor device to increase sensormeasurement intervals and/or transmission times, such as from once per30 mins to once every 5 mins.

FIG. 18B shows an example route having a series of points 1870, 1872,1874, 1876 through which a sensor device should pass through on way to adestination. For example, the route can be an interstate truck route. Ascan be seen, a route deviation 1878 occurs at a certain point. Thedeviation 1878 may occur for any number of legitimate and illegitimatereasons including traffic, weather conditions, operator error, and/ ortheft. In an embodiment, upon detection that the sensor device is morethan a select number of miles from the route defined between points1872, 1874, the cloud commands the sensor device to increase sensor datacollection and/or data transmission.

In another example, the sensor device can detect sensor data deviationsand reconfigure one or more parameters. For example, temperaturereadings can detect 1-sigma, 2-sigma, etc., deviations. Aftertransmission of the data to the cloud and/or onboard processing, fordetection of the temperature deviation, the sensor device increasesfrequency from every 20 mins to every 1 min on sensing to ensure that atemperature profile has sufficient resolution.

In another example, the sensor device can detect shocks after which thedevice may take certain actions, such as initiate and/or increase sensormeasurements, transmit sensor data, and the like. After detection ofshock data anomaly, such as multiple shock events in a relatively shortperiod of time, the sensor device can be reconfigured to transmit datamore frequently. In embodiments, the sensor device can detect the shockanomaly and/or the cloud can detect the shock anomaly resulting in acommand to the sensor device.

In another aspect, a sensor device includes waypoint configurationshaving different settings for various parameters. As the sensor devicereaches respective waypoints, a corresponding waypoint causes the sensordevice to be reconfigured.

In an example embodiment, a sensor device includes three waypoint (WP)configurations:

CONFIGURATION #1:

-   -   GPS OFF,    -   Cellular Location ON,    -   WiFi-Based Location OFF,    -   Transmission Frequency: every 1 hour    -   Sensing of Temperature, Humidity: every 20 mins    -   Shock Sensing: anything above 8 Gs

CONFIGURATION #2:

-   -   GPS ON,    -   Cellular Location ON,    -   WiFi-Based Location ON,    -   Transmission Frequency: every 20 mins    -   Sensing of Temperature, Humidity: every 5 mins    -   Shock Sensing: anything above 4 Gs

CONFIGURATION #3:

-   -   GPS ON,    -   Cellular Location ON,    -   WiFi-Based Location ON,    -   Transmission Frequency: every 5 mins    -   Sensing of Temperature, Humidity: every 1 min    -   Shock Sensing: anything above 2 Gs        The sensor device can be configured for expected waypoints        (geofenced [GEOREFERENCED? locations) for a selected route. For        example:    -   WP #1: Factory in Detroit where product is manufactured and        shipped from, and tracker is placed.    -   WP #2: Distribution center of the shipping carrier    -   WP #3: Warehouse where product is stored for shipping to        end-consumer

As shown in FIG. 18C, when the sensor device initializes, CONFIG #2(CF#2) can be utilized. When the sensor device is 5 miles, for example,away from WP#1, CONFIG #1 (CF#1) can be applied so that the sensordevice transmits less frequently. For example, the sensor device andassociated shipping container are on an interstate journey that is goingto take multiple days to get to WP#2. When the sensor device approachesWP#2 (e.g., within 10 miles), CONFIG #2 can be applied until it reachesthe Distribution Center (DC). There, the sensor device transitions backto CONFIG #1 after two hours since it has reached the DC at WP#2. Oncethe sensor device is within 20 miles of the warehouse at WP#3 where mosthandling of the shipping container will occur, and the loading docks arescheduled accordingly, the sensor device transitions to CONFIG #3 toincrease the amount of sensor data monitored and transmitted. Forexample, and estimated time of arrival (ETA) can be determined for theloading dock with desired resolution.

A similar approach can be used for a factory that utilizes Just-In-Time(JIT) delivery which requires continuous monitoring of suppliershipments. Consider an inbound example as follows:

-   -   WP #1: Supplier of parts in Wisconsin places the tracker in the        shipment.    -   WP #2: Distribution center of the shipping carrier    -   WP #3: Manufacturing site where the supplier part is crucial on        building the final products.

Any practical number of waypoints and corresponding configurations canbe set to meet the needs of a particular application, such as customerneeds. Waypoints can be provided for a wide range of geographiclocations and types of entities, such as seaports, airports, trainstations, etc.

Another example is that when sensor device arrives at a seaport, thesensor device can transition to a seaport waypoint configuration totransmit at every 6 hours or every 12 hours since the shippingcontainer/device is going to a ship and there is no need to attemptfrequent transmission in the middle of the ocean. In addition, when thesensor device arrives at a different port that is close to thedestination, the sensor device can transition to a waypointconfiguration profile with more frequent reporting and/or sensing.

In another embodiment, a sensor device can transition to differentconfigurations based on weather conditions at a particular location. Forexample, if there is a thunderstorm across an area at which the sensordevice is present, a storm configuration, which can be sent to thesensor device by the cloud, for example, can better monitor thecondition of the goods that are being transported.

In another embodiment, a stoppage configuration can be provided. Forexample, the sensor device can transition to a stoppage configurationbased on information, such as strikes in airports or transportationsystems. If there is a truck-driver employee strike in Paris, forexample, goods may not move during the strike, e.g., for several days.Until the strike or other stoppage event ends, the sensor device can beconfigured to take less frequent sensor measurements and/or datatransmissions.

It is understood that the configuration profiles can include settingsfor any sensor data collection parameter and/or any data transmissionparameter described herein.

FIG. 19 is a table showing some of the features being added to LTEstandards 1900 in order to support low power connectivity. The focus onthe new LTE standards such as LTE-MTC, eMTC, and CIOT proposal are aclear sign that the industry is progressing towards standardization ofnetworks together with end user wireless devices that can work on longdistances (e.g., WWAN) and still be able to consume the least amount ofpower when communicating. This push is ideal for the devices describedherein, which will be able to utilize any future improvement in cellularcommunication protocols to its advantage to further reduce powerconsumption and send sensor readings. In the new LTE standards modessuch discontinuous receive (DRX) and discontinuous transmit (DTX) areenabled and the current proposed solution is ready to take advantage ofthe upcoming standards by efficiently turning on and off certainmodules, chipsets, other components of the device. This could also beapplied in turning on and off certain cellular transceiver's internalblocks to achieve high efficiency and increase battery lifetime.

FIG. 20 illustrates an exemplary process of collecting and sorting datafor sensors such that display over time could be fast and efficient inaccordance with one or more embodiments. The best way to depict thisapproach is by using an example of one sensor reading where the updaterate is set to every 30 seconds. This would lead to 24*60*2=2880 datapoints per day, and that would lead to average of 30*2880=86400 datapoints per month and 12*86400=1,036,600, more than a million data pointsper year. If the request from the user is to display multiple sensorreadings over a year, getting a million data points for each sensorwould be very inefficient and would cause delays in retrieving anddisplaying such data. This would result in user experience that is notdesirable. In order to improve this experience, a filter or buffer isdesigned in the cloud architecture such that data is pre-processed forthe most optimal experience. The data is averaged on hourly sensorreadings and stored in a separate table, averaged daily for all hourreadings, average weekly on all daily readings, and finally averagemonthly on all daily readings. Having multiple tables would allow theend application to retrieve the data more efficiently (e.g., only 12data points for the entire year or 365 data points for the entire year).This would result in an improved user experience and reduction in datadisplay latency. This down sampling of data approach further improvesuser experience.

FIG. 21 illustrates an exemplary data verification and data integrityflow in accordance with one or more embodiments using a checksum toverify sensor data coming from the device. In one embodiment, the data2102 from the sensor reading is serialized 2104 in order to consume theleast amount of data space, through JSON or other protocols and then itis sent to a checksum algorithm 2106 and that could be a simple CRCalgorithm or any other depending on the microprocessors capability torun the algorithm. In addition to the serialized data, the checksum andthe sensor data length 2108 is then added to the message to make surethat its integrity is intact. After this process is complete the data issent to the cloud 2110 through various means described above.

FIG. 22 shows use of a combination of GPS/GNSS, cellular location,Wireless Local Area Network and/or Wireless Personal Area Network to geta more accurate location for the device in accordance with one or moreembodiments. The device 2202, which in addition to the sensors, containsthe WWAN 2206, WPAN 2204, and GPS/GNSS 2008 capability. There aremultiple third party APIs that can be utilized for the cellular, WiFi,BLE location. The WWAN cellular based information gives the device anidea of the cell base stations that it is connected to, which then canbe utilized to get a rough estimate of its location. The GNSS enableddevice also gets a 2D or 3D fix on the location of the device dependingon the location of the device whether it could receive the satellitesignals 2208. Another way of obtaining location of the device is throughWPAN network by accessing databases that contain location of variousfixed Bluetooth beacons or WiFi hotspots.

FIG. 23 shows an exemplary network diagnostic application in accordancewith one or more embodiments at various locations and next toDistributed Antenna Systems (DAS) or Base Terminal Stations (BTS). Inone embodiment multiple devices 2318 2320 2322 and 2324 are placed nextto various network BTS towers 2304 2306 2308 and also distributedantenna systems (DAS) 2302. The devices then perform spectrum analyseson various bands for GSM, UMTS, LTE, and other standards and send thatdata back to the cloud 2314. This monitoring allows a user to use adashboard 2316 to review and manage spectrum of each BTS tower and DASlocation. This could enable a user to set threshold for spectrum powerto make sure that unlicensed and unallocated signals do not suddenlyappear in licensed bands. This spectrum monitoring dashboard would looksimilar to FIG. 15 b.

FIG. 24 shows various antenna placements for GPS/GNSS, WWAN, WPAN, andWLAN connectivity on a device in accordance with one or moreembodiments. The GPS/GNSS antenna 2400 can be a flexible and stickerlike antenna that is attached on the case 2406. The multi-band cellular(WWAN) antenna 2402 is a separate PCB that is placed on the side of thedevice 2408. The Bluetooth antenna 2404 (2.4 GHz in one embodiment) forWPAN is shown and is also placed on a separate PCB that is placed on theopposite side of the device where the cellular antenna 2402 resides.

FIG. 25 shows a reusable plastic container application with rechargeablebatteries in a stackable fashion in accordance with one or moreembodiments. The devices 2514 are attached to the reusable plasticcontainers (RPCs) 2512 in a way such that they could be stackable 2506and the power on each device could be stacked using USBs or othercharging ports 2510. The stacked RPCs could then be plugged 2504 to apower source 2502 to charge overnight or when they are not beingutilized inside a truck or a warehouse. Once the batteries 2508 insidethe device are fully charged the RPCs could travel with various itemssuch as tomatoes, produce, perishables, live cultures, and other itemsthat are sensitive to various environmental changes. The environmentalsensor together with the GPS/Cellular/WPAN/WLAN based location aregenerated from the device 2514 and sent to the cloud for tracking andalerting the end user if any undesired thresholds have been reached.

FIG. 26 illustrates an exemplary primary dashboard user interface 2600for Sensing as a Service Platform and Web Application in accordance withone or more embodiments. The Sensing as a Service can be implemented asa web application for a web browser, a desktop application, a smartphone(e.g., iOS, Android, Symbian OS, or other OS) app, or any other softwareplatform. The user interface can display all linked devices 2602 withinleft column. Users can switch between viewing detail information byclicking on device name listed vertically in the left column. Sensoralert level indicator 2602 is displayed to the left of device name.Selected device name and current calculated device location 2604 isdisplayed within the detail information pane. Module network connection,Bluetooth connection indicator, battery life level and devicepreferences control button are listed in top header 2606.

Individual sensor metrics (2608, 2610, 2612, 2614, 2616, 2618) aredisplayed in a grid interface below the selected sensor pane 2620. Adynamic graphical diagram, alert threshold settings, and additionaldetail information are available for each sensor metric when user clickson sensor metric block.

The temperature sensor block 2608 displays current temperature level,the value change from previous reading, and the 24-hour high and lowvalues. The sensor block also displays current alert state, shown inthis example by a color alert indicator. Clicking on temperature detail2608 initiates a change in selected sensor pane 2620.

The current device location detail block 2610 displays activity timer,current approximated location address, trip time, and trip distance.Trip time is a running timer that is reset after a certain amount oftime (e.g., 30 minutes) of device inactivity. The trip distance is totaldistance traveled during that trip time. The location detail interface2620 is the selected sensor detail for this figure.

The speed sensor block 2612 displays current speed, the value changefrom previous reading and the 24-hour high and low values. The speedsensor block also displays current alert state, shown here by grey alertindicator. Clicking on speed detail 2612 initiates a change in selectedsensor pane 2620.

The humidity sensor block 2614 displays current humidity level, thevalue change from previous reading, and the 24-hour high and low values.The humidity sensor block also displays current alert state, shown hereby grey alert indicator. Clicking on humidity detail 2614 initiates achange in selected sensor pane 2620.

The light sensor block 2616 displays current light level indication inmatching light state and the LUX level. Level indication is derived fromstandard light level ranges. Sensor block also includes a horizontallyoriented light level gradient and current level indicator. Sensor blockalso displays current alert state, shown here by grey alert indicator.Clicking on light detail 2616 initiates a change in selected sensor pane2620.

The pressure sensor block 2618 displays current pressure level, thevalue change from previous reading, calculated altitude, and the 24-hourhigh and low values. The pressure sensor block also displays currentalert state, shown here by grey alert indicator. Clicking on pressuredetail 2618 initiates a change in selected sensor pane 2620.

The sensor blocks cab adjusted in an order that the user prefers andthey can also support additional sensor metrics that other than the onesshown in FIG. 26.

Within the location sensor detail pane 2620, real-time device locationis displayed 2622. Previous sensor transmission points can be indicatedby points located to the north of current sensor location in thediagram. If one sensor metric value is above or below a set threshold atthe time of transmission, the point is colored. Points are clickable andinitiate a detail pane. Detail pane contains historical sensor metricdata.

Other available views to location sensor detail are available to theuser. Current selected state is the map location. Users can switch toview activity graph or preferences view by clicking on control buttons2624.

All alerts within 24-hour period are listed in right column 2626. Thecolumn contains current region time, calculated by location. Alerts areordered by most recent alert at top. Individual sensor alert itemscontain number of individual alert instances for that sensor and timeelapsed since most recent alert event. Clicking on item verticallyexpands that selected alert notification, pushing other alert itemsdown. In expanded state, individual alert events are presented with thevalue of alert and amount of time elapsed at the value.

The Account Name is displayed 2628 within the top-level header. Clickingname reveals general account navigation items including sign out.

FIG. 27 illustrates an exemplary device preferences interface 2700 ofthe Sensing as a Service Dashboard in accordance with one or moreembodiments. In this example, the preferences page is accessed byclicking on gear icon 2702 from within the Web Application. There existfour primary preferences categories, General 2704, Module Sensors 2706,Cellular Network 2708 and Communication Settings 2710.

General preferences 2704 includes Device Name, Device ID Number, andAlert Contact Information such as cell phone number, email address,smartphones linked to the account where push notifications can be sent.Device name, cell phone number and email address are editable by theuser by clicking on the item. Once a user has finished editing thevalue, a confirmation message is initiated. Before updating the userdevice information, the entered values are verified to be valid inputs.If an input is not valid, an error message is served.

Cellular Network 2706 displays current cellular network on which thedevice is connected, the signal strength, and cellular data usage. Datausage is displayed as an aggregate of all data across all networks.Current period and lifetime usage are available. The user also has theability to set usage alerts. Alert would be sent to defined cell numbervia SMS, or defined email address via email when data usage is reachingpredefined period limits. The user could also get notifications on theweb based application, desktop application, or push notifications ontheir smartphone app.

Device Sensor preferences 2708 enable the user to toggle individualsensors On/Off. This preferences block is the primary workflow thatdefines the Sensing as a Service Platform and Web Application.Individual sensors are activated via monthly subscription. Additionalsensors not available to user account can also be activated from withinthe Web Application. Clicking Activate button launches a subscriptionworkflow. The subscription confirmation contains particular monetarysubscription values for each sensor with associated term definitions.There could be different pricing plans such as affordable sensor bundlesin which a user unlocks a set of sensor metrics for a reduced rate. Forexample, a Climate package could include temperature, humidity, andpressure at a certain value per month or year.

Communication Settings preferences 2710 displays sensor datacommunication frequency, calculated estimated battery life at theselected communication frequency, Bluetooth communications toggle andbattery life information. Clicking on frequency dropdown displaysalternative periods of communication. Based on selected period length,the estimated battery life is calculated and displayed in format ofDays, Hours, Minutes. Bluetooth connection toggle turns communicationOn/Off. Current battery life is displayed with low battery alertcontrol. If alert is set to On position, an alert would be sent todefined cell number via text and/or email address via email when batterylife reaches 20%, 10% and 5%.

FIG. 28 illustrates alternate exemplary case designs for the electronicdevice in accordance with one or more embodiments. In one example, thedevice can be in different colors as shown in white 2802 and black 2804.The USB port can also be a micro USB 2806 and multiple LED lightindicators 2808 can be provided to convey various states of the deviceas shown in FIG. 1E.

FIG. 29 illustrates an exemplary case of an electronic device 2902having a clip attachment 2906 in accordance with one or moreembodiments, which allows the device to be attached as a clip-on to aperson 2908 that is being monitored and tracked. (In an alternativeembodiment, the case can be attached to a wristband wearable by theperson.) This device is particularly useful for Alzheimer, Autistic, andother at risk or elderly users. In one embodiment, this device isutilized to track the whereabouts of the patient 2910. A perimeter, box,square, rectangle, hexagon, octagon, polygon, or other shape 2918 is setaround the residence. The device is configured to report back to theserver using the WAN connectivity module, or through WPAN or WLANconnectivity modules depending on the residence and if there isWLAN/WPAN connectivity available that connects to the internet. When theperson is inside the residence 2914, or inside the perimeter 2918 asindicated at 2912 and 2916, the GPS/GNSS coordinates read that the useris within the perimeter. However, if the user or person starts to wanderaway (indicated at 2910) from the perimeter 2918, the device reports itback to the server and end user is alerted. All other sensor metricsalso inform key lifestyle states which can be set to alert the end user.Examples of this include, exceeding a set period of inactivity time ortemperature alert for high/low temperatures, both indicating thatsomething is out of the ordinary and may require attention.

FIGS. 30A and 30B show an exemplary PCB layout (top and bottom sides ofthe PCB) in accordance with one or more embodiments for a device wherethe type C USB 3008 could be used as a charger and as an adapter toprogram the internal processor (such as ARM, Intel, Renesas, or others)or a microcontroller using SWD or JTAG interface 3006 and 3004. In thisexemplary PCB design the USB type-B 3010 is shown and used to connect toa computer or other serial USB interface for connecting the said devicedirectly to the serial control link using its Type C 3008 connection.The connector 3006 is used for SW/JTAG type of communication with J-LINKor other products that are used for programming and debugging ofmicro-controller processors (MCUs).

FIG. 31 is a flow chart that illustrates exemplary sensing as a servicein accordance with one or more embodiments. The first step 3102 of theprocess involves the user attempting to login to the sensor managementand provisioning dashboard. In the next step, the user is authenticatedand if the username and password are correct the user is directed to thedashboard 3104 where a display of all activated and deactivated sensorsare presented. If login information is incorrect, an error message isserved. In one embodiment, the temperature, pressure, and humiditysensors can be activated and every other sensor such as: GPS/GNSSlocation, cellular location, accelerometer, gyroscope, magnetometer,volatile organic compound detector, light sensor, infrared sensor,Bluetooth based location, and RF spectrum power monitor are deactivated.In the next step 3106, the user selects a few or all available sensorsfor activation. For example, the accelerometer and gyroscope could beselected for activation. As a result, a confirmation message isgenerated 3108 to ask the user to accept the terms and conditions andalso the fees for the subscription to the two sensors as chosen in thisexample. The fee structures could be setup to be charged weekly,monthly, or any other time period. In addition, depending on when a userhas subscribed to a set of sensors, the sensor fees could be proratedsuch that the billing cycle matches to the cycle that the user hasinitially chosen. The subscription model can also be setup such thateach sensor is charged independently. Further, a new billing cycle canbe setup and old sensor subscription fees could be prorated to match thenew sensor billing cycle. After the user accepts the terms and fees(could also be free depending on the service) the sensors are enabled3110 in this example and shown in the dashboard. In addition, duringthis step 3110, the electronic device is also configured to enable ordisable one or more sensors depending on the activation or deactivationchoice by the user.

FIG. 32 illustrates an exemplary alert perimeter for the location sensorsuch that when the electronic device goes outside of the perimeter itnotifies the central server and user about its location and tracks theelectronic device and its whereabouts. In this example, multi-pointshape 3202 is created, and that shape could also be a random multi-pointshape, square, circle, ellipse, polygon, or any other shape that theuser could draw using a pencil tool in the application.

FIG. 33 is a block diagram illustrating components of a multi-sensorelectronic device in accordance with one or more embodiments. The deviceincludes a microcontroller (MCU) 3326, such as STM32 which is an ARMbased microcontroller, or any other microcontroller or microprocessor.The memory 3328 is also connected to the MCU and the sensor data can besaved on the memory when the wireless connectivity is not available tosend the data to the Internet. The device includes multiple sensorsincluding, but not limited to: (1) inertial measurement unit (IMU) 3302,which has an accelerometer, gyroscope, magnetometer, motion detector,and orientation output for the device, (2) environmental sensors, whichare comprised of a temperature sensor, humidity sensor, pressure sensor,and volatile compound detector 3304, (3) visible light and infraredsensor 3308, (4) radio frequency (RF) spectrum power sensor 3310 forvarious frequencies in the cellular bands. The device further includesGPS/GNSS receiver 3314 to provide longitude, latitude, speed, and otherinformation that is available from GPS/GNSS receivers. The device alsoincludes alarm sound buzzer 3306 used for finding the device or for anyalerts or system information. The device also includes a multi-color LEDindicator, which can be used as described in one example in FIG. 1E. Thedevice further includes a WWAN cellular connectivity module 3324 thatcan work in various standards (2G/3G/4G), various bands, and variousmodes of operation. The device also includes a WPAN Bluetooth module3322 that is used to communicate with other devices such as smartphonesor other multi-sensor electronic device to form a mesh network. Thedevice also includes antennas for GPS 3316, cellular connectivity 3318,and Bluetooth 3320. The cellular antenna could be changed to meet globalcellular coverage requirements for 2G, 3G, 4G and 5G connectivity in thefuture.

The GPS/GNSS receiver 3314 can be a separate receiver or incorporatedinside the WWAN cellular connectivity module 3324. The WPAN module 3322could also be a ZigBee, Z-Wave, 6LoWPAN, or any other personal areanetwork module. The WWAN module could meet one or more or anycombination of cellular standards such as: GSM, UMTS, CDMA, WCDMA, LTE,LTE-A, LTE-Cat1, LTE-Cat0, LTE-MTC. WWAN module 3324 could also be aLoRA or a Sigfox module that connects to the non-cellular networkfocused of machine-to-machine (M2M) communications. WWAN module 3324 canbe any other module that functions in wide area using wireless means ofcommunication.

FIG. 34 is a flowchart illustrating an exemplary user sign in and signup process in accordance with one or more embodiments to access thesensor management dashboard (web application). If user has an existingaccount and has already set up their account information, that user willenter the sign in flow from the primary website 3402 or directly throughthe sign in/sign up form page 3404. If submitted credentials are valid,user is directed to the primary dashboard page illustrated in FIG. 26and represented here as Sensor Management Dashboard 3420. If logincredentials are not valid, user will have ability to select a ForgotPassword link to retrieve a token URL to reset account information. Uponresetting password, an alert notification will be sent to user email andphone number contacts.

If user does not have an existing account and is setting up account anddevices for the first time 3404, the user selects sign up (createaccount) from available options on the sing in/sign up page. The userlaunches sign up process 3408 to activate account and add devices toaccount. Upon starting sign up flow, the user is prompted to entergeneral user information (name, email, phone number, address, company)3410. The user is then prompted to link purchased devices to thataccount 3412. The user is able to add devices by either (1) turning onsmart phone Bluetooth connection and selecting device from list ofnearby turned on devices that are transmitting a Bluetooth signal or (2)entering device ID number to form field or (3) scanning a QR on deviceor (3) scanning a barcode on the device. At this time, when a user isadding devices to account, the user is able to give the device a customname. Once all devices have been linked to an account, user is directedto the initial device setup interface 3414 in which they will do aninitial setup of the individual device preferences (Fahrenheit orCelsius, Imperial or Metric units, which sensors are on/off and anyassociated alert thresholds). After completing this step, the user willhave ability to add other members to their team and set up account types(admin, general--no editing rights). Invitation to join the sensormanagement portal for network of devices will be sent in email form toindicated email addresses. These users will then enter the sign up flowfrom a URL 3406. Upon sending additional member invitations, user isguided through a tutorial process of the dashboard 3420 which highlightskey functionality. This tutorial is also available at any time to loggedin users within the account information page. At completion of tutorialuser is directed to the primary dashboard interface.

If a user is brought to the sign up process through an invitation link,the user is immediately prompted with the identical user informationfields 3418, also presented in 3410. Upon completing this step, user isguided through a tutorial process of the dashboard 3420. At completionof tutorial user is directed to the primary dashboard interface.

FIGS. 35A and 35B illustrate an alternative exemplary case design 3502for a device in accordance with one or more embodiments. A clip 3504shown in FIGS. 35C and 35D can be removably attached to the case 3502 tosecure the device to a package, pallet, or other asset.

Having thus described several illustrative embodiments, it is to beappreciated that various alterations, modifications, and improvementswill readily occur to those skilled in the art. Such alterations,modifications, and improvements are intended to form a part of thisdisclosure, and are intended to be within the spirit and scope of thisdisclosure. While some examples presented herein involve specificcombinations of functions or structural elements, it should beunderstood that those functions and elements may be combined in otherways according to the present disclosure to accomplish the same ordifferent objectives. In particular, acts, elements, and featuresdiscussed in connection with one embodiment are not intended to beexcluded from similar or other roles in other embodiments. Additionally,elements and components described herein may be further divided intoadditional components or joined together to form fewer components forperforming the same functions.

Accordingly, the foregoing description and attached drawings are by wayof example only, and are not intended to be limiting.

What is claimed is:
 1. A method, comprising: configuring a sensor devicein accordance with a first configuration defining data collection for aplurality of sensors and defining when the collected data for thesensors is transmitted to a remote network, wherein the sensor device iscoupled to an asset or good being shipped for collecting the data as theasset or good is en route to a destination; receiving a reconfigurationsignal by the sensor device from the remote network comprising aconfiguration change from a first configuration to a secondconfiguration; and determining, whether the device should perform theconfiguration change to the second configuration based on an event.